Упродовж останнього року-двох було запропоновано кілька розширень, що пропонують угоди щодо розширень до Біткойна, завжди існувала підозра серед експертів, що можливі без будь-яких розширень. Докази цього надійшли у двох формах: розширення репертуару раніше вважаних неможливими обчислень в (що завершилося проектом BitVM з реалізації кожного опкоду RISC-V), та серії "практично-промахів", за якими розробники Біткойн знайшли шляхи, які були б можливими для угод, якби не якийсь темний історичний каприз .
Етан Хайльман, Авігу Леві, Віктор Коболов і я розробили схему, яка доводить, що ця підозра була добре заснованою. Наша схема,Колайдер**, дозволяє укладати угоди на Біткойн сьогодні, за досить розумних криптографічних припущень та ймовірною вартістю близько 50 мільйонів доларів за транзакцію (плюс деякі апаратні дослідження та розробки).*
Незважаючи на надзвичайні витрати на використання Колайдера, його налаштування є дуже дешевим, і таке (разом звичайним механізмом витрат, використанням Taproot для розмежування двох) може врятувати ваші монети в разі появи квантового комп'ютера з нікуди і його вибуху.
Без сумніву, багато читачів, після прочитання цих тверджень, піднімають брову до неба. Коли ви закінчите читати цю статтю, інша буде так само високою.
Ковенанти
Контекст цієї дискусії, для тих, хто не знає, полягає в тому, що у Біткойну є вбудована мова програмування, яка називається Біткойн , яка використовується для авторизації витрати монет. У свої початкові дні містив багатий набір арифметичних опкодів, які можна було використовувати для реалізації довільних обчислень. Але влітку 2010 року Сатоші вимкнув багато з них, щоб придушити серію серйозних помилок. (Повернення до версії до 2010 року - це мета Великого проекту відновлення; OP_CAT - менш амбіційна пропозиція в тому ж напрямку.) Ідея угод - транзакції, які використовують для контролю кількості та призначення своїх монет - з'явилася лише через кілька років, і реалізація того, що ці опкоди були б достатніми для реалізації угод, з'явилася ще пізніше. До того моменту спільнота була занадто великою та обережною, щоб просто "увімкнути" старі опкоди так само, як вони були вимкнені.
Ковенанти - це гіпотетичні конструкції, які дозволили б користувачам контролювати не лише умови, за яких витрачаються монети, а й їх призначення. Це є основою для багатьох майбутніх конструкцій на Біткойн, від сховищ і обмежених за рахунком гаманців до нових механізмів ринку комісій, таких як платіжні пули, до менш приємних конструкцій, як розподілений фінанси та MEV. Мільйони слів було витрачено на обговорення бажаності ковенантів та їх впливу на природу Біткойн.
У цій статті я обійду цю дискусію стороною і буду просто стверджувати, що ковенанти вже можливі на Біткойн; що ми в кінцевому підсумку відкриємо як вони є можливими (без великих обчислювальних витрат або сумнівних криптографічних припущень); і що наша дискусія про нові розширення для Біткойн не повинна бути сформульована так, ніби окремі зміни будуть роздільною лінією між майбутнім безковенантним або повним ковенантом для Біткойн.
Історія
З роками виникла традиція знаходження творчих способів робити незвичайні речі навіть з обмеженими можливостями. Мережа Lightning була одним з прикладів цього, так само як менш відомі ідеї, такі як ймовірні платежі або винагороди за зіткнення для хеш-функцій. Невідомі випадки, такі як помилка SIGHASH_SINGLE або використання відновлення відкритого ключа для отримання "хешу транзакції" в мові програмування, були помічені та досліджені, але ніхто ніколи не знайшов способу зробити їх корисними. Тим часом, Біткойн сам по собі еволюціонував, щоб бути більш жорстко визначеним, закриваючи багато з цих можливостей. Наприклад, Segwit усунув помилку SIGHASH_SINGLE та явно відокремив дані програми від даних свідка; Taproot позбавив можливості відновлення відкритого ключа, яке забезпечувало гнучкість за рахунок потенційного підриву захисту для адаптивних підписів або мультіпідписів.
Незважаючи на ці зміни, хакерство продовжувалося, як і віра серед затятих людей у те, що якимось чином може бути знайдений якийсь крайній випадок, який уможливить підтримку ковенанту в Біткойн. На початку 2020-х років дві події, зокрема, викликали фурор. Одним з них було моє власне відкриття, що ковенанти, засновані на підписах, не померли при відновленні відкритого ключа, і що, зокрема, якби у нас був хоча б один відключений код операції назад - OP_CAT - цього було б достатньо для досить ефективної побудови ковенантів. Другим був BitVM, новий спосіб виконання великих обчислень у кількох транзакціях, який надихнув на величезну кількість досліджень базових обчислень в рамках однієї транзакції.
Ці два розвитки надихнули багато активності та захвату навколо завітів, але вони також укристалізували наше мислення про фундаментальні обмеження . Зокрема, здавалося, що без нових опкодів завіти можуть бути неможливими, оскільки дані транзакцій подавалися лише через 64-байтові підписи та 32-байтові відкриті ключі, тоді як опкоди, що підтримують BitVM, могли працювати лише з 4-байтовими об'єктами. Це розрив був названий "Малий " та "Великий ", і знаходження мосту між ними стало синонімом (принаймні у моїй думці) знайти конструкцію завіту.
Функціональне шифрування та PIPEs
Також було зауважено, що за допомогою трохи місячної математики, можливо здійснювати ковенанти повністю всередині підписів, не залишаючи великого, ніколи не залишаючи Великого . Ця ідея була сформульована Джеремі Рубіном у його доповіді FE'd Up Covenants, де описано, як реалізувати ковенанти за допомогою гіпотетичної криптопримітивної функціональної шифрування. Місяці пізніше Міша Коморов запропонував конкретну схему, яка, здається, зробила цю гіпотетичну ідею реальністю.
Це захоплюючий розвиток, хоча він стикається з двома основними обмеженнями: одне полягає в тому, що воно включає довірений налаштування, що означає, що особа, яка створює договір, здатна обійти його правила. (Це підходить для чогось такого, як сховища, в яких власник монет може довіряти тому, що не підірветься його власна безпека; але це не підходить для чогось такого, як платіжні пули, де монети в договорі не належать творцеві договору.) Іншим обмеженням є те, що воно включає передову криптографію з неясними властивостями безпеки. Це останнє обмеження зникне з додатковим дослідженням, але довірений налаштування є неодмінним для функціонального підходу до шифрування.
Колайдер
Цей огляд доводить нас до поточної ситуації: ми хотіли б знайти спосіб реалізації договорів за допомогою існуючої форми Біткойн , і ми вважаємо, що шлях до цього полягає в знаходженні якогось мосту між "Великим " підписами транзакцій та "Малим " довільними обчисленнями. Здається, що жоден опкод не може прямо сформувати цей міст (див. Додаток A до нашої статті для класифікації всіх опкодів за розмірами їх вводу та виводу). Міст, якщо б він існував, був би якоюсь конструкцією, яка б взяла один великий об'єкт і продемонструвала, що він точно дорівнює конкатенації кількох малих об'єктів. Здається, на основі нашої класифікації опкодів, це неможливо.
Але в криптографії ми часто ослаблюємо такі поняття, як "точно рівні", замість цього використовуючи поняття, такі як "обчислювально нерозрізнимі" або "статистично нерозрізнимі", тим самим уникнувши неможливих результатів. Можливо, використовуючи вбудовані криптографічні конструкції Big - хеші та еліптичні криві підписи - і дзеркалюючи їх за допомогою конструкцій BitVM в Small, ми зможемо знайти спосіб показати, що великий об'єкт є "обчислювально нерозрізним" від серії малих об'єктів? За допомогою Collider ми саме це й зробили.
Що це означає? Ну, пригадайте винагорода зіткнення хеш-функції, про яку ми згадували раніше. Премісцюється цієї винагорода полягає в тому, що будь-хто, хто може "зіткнутися" з хеш-функцією, надавши два входи, які мають однаковий вихід хеш-функції, може довести в Біґ, що вони це зробили, і таким чином вимагати винагорода. Оскільки простір входу хеш-функції набагато більший (всі байтряди розміром до 520 байт) від простору виходу (байтряди розміром точно в 32 байти), математично кажучи, має бути багато таких зіткнень. І все ж, за винятком SHA1, ніхто не знайшов швидший спосіб знайти ці зіткнення, ніж просто безперервно викликати хеш-функцію і перевіряти, чи співпадає результат з результатом попереднєї спроби.
Це означає, що у середньому для функції хешування 160-біт, такої як SHA1 або RIPEMD160, користувачеві потрібно виконати принаймні 2^80 роботи, або мільйон мільйонів мільйонів мільйонів ітерацій, щоб знайти зіткнення. (У випадку SHA1 існує скорочення, якщо користувач може використовувати вхідні дані певної форми; проте наша конструкція забороняє це, тому для наших цілей ми можемо ігнорувати цей напад.) Це передбачає, що у користувача є практично нескінченна кількість пам'яті для роботи; з більш реалістичними припущеннями нам потрібно додати ще один множник близько ста.
Якщо уявити, що SHA1 та RIPEMD160 можна обчислити так само ефективно, як Біткойн ASIC-пристрої обчислюють SHA256, то вартість такого обчислення буде приблизно такою ж, як вартість 200 блоків, або близько 625 BTC (46 мільйонів доларів). Це багато грошей, але багато людей мають доступ до такої суми, тому це можливо.
Знайти трипльне зіткнення, або три входи, які дорівнюють одному й тому ж, займе близько 2^110 роботи, навіть за дуже щедрими припущеннями про доступ до пам'яті. Щоб отримати цю цифру, нам потрібно додати ще один множник 16 мільйонів до наших витрат - це збільшить нашу загальну суму до понад 700 трильйонів доларів. Це також багато грошей, на які ніхто не має доступу сьогодні.
Суть нашої конструкції полягає в наступному: для того, щоб довести, що послідовність малих об'єктів еквівалентна одному великому об'єкту, спочатку ми знаходимо хеш-колізію між нашим цільовим об'єктом (який, як ми припускаємо, може бути перерандомізований якимось чином, інакше ми б займалися «пошуком другого образу» замість пошуку колізій, що було б набагато складніше) та «об'єктом-тестером еквівалентності». Ці об'єкти-тестери еквівалентності будуються таким чином, що їх можна легко маніпулювати як великими, так і малими.
Наша конструкція потім перевіряє, у Біткойні, що наш великий об'єкт зіштовхується з нашим тестером еквівалентності (використовуючи точно ті ж методи, що і в хеш-колізії винагороди) та що наша послідовність малих об'єктів зіштовхується з тестером еквівалентності (використовуючи складні конструкції, частково позичені з проекту BitVM, та детально описані у статті). Якщо ці перевірки пройшли успішно, то або наші малі й великі об'єкти були однакові, або користувач знайшов потрійну колізію: два різні об'єкти, які обидва зіштовхуються з тестером. За нашим аргументом вище, це неможливо.
Висновок
Поєднання малого і великого—це найважча частина нашої побудови завітів. Щоб перейти від цього щастя до справжнього завіту, потрібно зробити ще кілька кроків, які є порівняно легкими. Зокрема, ковенант спочатку просить користувача підписати транзакцію за допомогою спеціального «ключа генератора», який ми можемо перевірити за допомогою коду операції OP_CHECKSIG. Використовуючи міст, ми розбиваємо цю сигнатуру на 4-байтові фрагменти. Потім ми перевіряємо, що його nonce також дорівнював ключу генератора, що легко зробити після того, як підпис був розбитий. Нарешті, ми використовуємо методи трюку Шнорра для вилучення даних про транзакції з підпису, які потім можуть бути обмежені будь-яким способом, який забажає ковенант.
Є ще кілька інших речей, які ми можемо зробити: Додаток C описує конструкцію кільцевого підпису, яка дозволить підписати монети одним з набору відкритих ключів, не розкриваючи, який саме був використаний. У цьому випадку ми використовуємо міст для розбиття відкритого ключа, а не підпису. Це дає нам значне покращення ефективності порівняно з конструкцією пакту за технічними причинами, пов'язаними з Taproot та детально описаними в документі.
Заявка, на яку я хочу звернути увагу, коротко обговорена в розділі 7.2 статті, це те, що ми можемо використовувати нашу конструкцію угоди, щоб витягти хеш транзакції з підпису Шнорра, а потім просто повторно підписати хеш з використанням підпису Лампорта.
Чому б ми це робили? Як аргументується в вищезазначеному посиланні, підписування Лампорта таким чином робить його квантово-стійким підписом для даних транзакції; якщо ця конструкція була єдиною можливістю підпису для деяких монет, вони були б захищені від крадіжки квантовим комп'ютером.
Звичайно, оскільки на наше будівництво потрібні десятки мільйонів доларів, ніхто не зробить цю конструкцію єдиним способом підписання своїх монет. Але ніщо не заважає комусь додати цю конструкцію до своїх монет, на додачу до існуючих неквантово-безпечних методів витрачання.
Тоді, якщо ми прокинулися завтра і виявили, що існують дешеві квантові комп'ютери, які можуть ламати підписи Біткойн, ми могли б запропонувати невідкладний м'який форк, який вимкнув би всі еліптичні криві підписи, включаючи як ключ-витрати Taproot, так і опкод OP_CHECKSIG. Це фактично заморозило б монети всіх; але якщо альтернативою було б те, що монети всіх можна було вільно вкрасти, можливо, це не зробило б жодної різниці. Якщо цей м'який форк, який вимикає підписи, дозволяв би опкод OP_CHECKSIG при виклику з ключем генератора (такі підписи взагалі не забезпечують безпеку і корисні лише як будівельний блок для складних конструкцій, таких як наші), то користувачі нашої конструкції підпису Лампорта могли б продовжувати вільно витрачати свої монети, не боячись конфіскації чи крадіжки.
Звичайно, їм доведеться витратити десятки мільйонів доларів на це, але це набагато краще, ніж "неможливо"! І ми очікуємо та сподіваємося, що ці витрати PEOPLE значно зменшаться, так як люди будують наші дослідження.
Це гостьовий пост Ендрю Поелстри. Висловлювані думки повністю є їх власними і не обов'язково відображають погляди BTC Inc або Біткойн Magazine.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Collider_: $50M Біткойн Covenant без нових опкодів
Упродовж останнього року-двох було запропоновано кілька розширень, що пропонують угоди щодо розширень до Біткойна, завжди існувала підозра серед експертів, що можливі без будь-яких розширень. Докази цього надійшли у двох формах: розширення репертуару раніше вважаних неможливими обчислень в (що завершилося проектом BitVM з реалізації кожного опкоду RISC-V), та серії "практично-промахів", за якими розробники Біткойн знайшли шляхи, які були б можливими для угод, якби не якийсь темний історичний каприз .
Етан Хайльман, Авігу Леві, Віктор Коболов і я розробили схему, яка доводить, що ця підозра була добре заснованою. Наша схема, Колайдер**, дозволяє укладати угоди на Біткойн сьогодні, за досить розумних криптографічних припущень та ймовірною вартістю близько 50 мільйонів доларів за транзакцію (плюс деякі апаратні дослідження та розробки).*
Незважаючи на надзвичайні витрати на використання Колайдера, його налаштування є дуже дешевим, і таке (разом звичайним механізмом витрат, використанням Taproot для розмежування двох) може врятувати ваші монети в разі появи квантового комп'ютера з нікуди і його вибуху.
Без сумніву, багато читачів, після прочитання цих тверджень, піднімають брову до неба. Коли ви закінчите читати цю статтю, інша буде так само високою.
Ковенанти
Контекст цієї дискусії, для тих, хто не знає, полягає в тому, що у Біткойну є вбудована мова програмування, яка називається Біткойн , яка використовується для авторизації витрати монет. У свої початкові дні містив багатий набір арифметичних опкодів, які можна було використовувати для реалізації довільних обчислень. Але влітку 2010 року Сатоші вимкнув багато з них, щоб придушити серію серйозних помилок. (Повернення до версії до 2010 року - це мета Великого проекту відновлення; OP_CAT - менш амбіційна пропозиція в тому ж напрямку.) Ідея угод - транзакції, які використовують для контролю кількості та призначення своїх монет - з'явилася лише через кілька років, і реалізація того, що ці опкоди були б достатніми для реалізації угод, з'явилася ще пізніше. До того моменту спільнота була занадто великою та обережною, щоб просто "увімкнути" старі опкоди так само, як вони були вимкнені.
Ковенанти - це гіпотетичні конструкції, які дозволили б користувачам контролювати не лише умови, за яких витрачаються монети, а й їх призначення. Це є основою для багатьох майбутніх конструкцій на Біткойн, від сховищ і обмежених за рахунком гаманців до нових механізмів ринку комісій, таких як платіжні пули, до менш приємних конструкцій, як розподілений фінанси та MEV. Мільйони слів було витрачено на обговорення бажаності ковенантів та їх впливу на природу Біткойн.
У цій статті я обійду цю дискусію стороною і буду просто стверджувати, що ковенанти вже можливі на Біткойн; що ми в кінцевому підсумку відкриємо як вони є можливими (без великих обчислювальних витрат або сумнівних криптографічних припущень); і що наша дискусія про нові розширення для Біткойн не повинна бути сформульована так, ніби окремі зміни будуть роздільною лінією між майбутнім безковенантним або повним ковенантом для Біткойн.
Історія
З роками виникла традиція знаходження творчих способів робити незвичайні речі навіть з обмеженими можливостями. Мережа Lightning була одним з прикладів цього, так само як менш відомі ідеї, такі як ймовірні платежі або винагороди за зіткнення для хеш-функцій. Невідомі випадки, такі як помилка SIGHASH_SINGLE або використання відновлення відкритого ключа для отримання "хешу транзакції" в мові програмування, були помічені та досліджені, але ніхто ніколи не знайшов способу зробити їх корисними. Тим часом, Біткойн сам по собі еволюціонував, щоб бути більш жорстко визначеним, закриваючи багато з цих можливостей. Наприклад, Segwit усунув помилку SIGHASH_SINGLE та явно відокремив дані програми від даних свідка; Taproot позбавив можливості відновлення відкритого ключа, яке забезпечувало гнучкість за рахунок потенційного підриву захисту для адаптивних підписів або мультіпідписів.
Незважаючи на ці зміни, хакерство продовжувалося, як і віра серед затятих людей у те, що якимось чином може бути знайдений якийсь крайній випадок, який уможливить підтримку ковенанту в Біткойн. На початку 2020-х років дві події, зокрема, викликали фурор. Одним з них було моє власне відкриття, що ковенанти, засновані на підписах, не померли при відновленні відкритого ключа, і що, зокрема, якби у нас був хоча б один відключений код операції назад - OP_CAT - цього було б достатньо для досить ефективної побудови ковенантів. Другим був BitVM, новий спосіб виконання великих обчислень у кількох транзакціях, який надихнув на величезну кількість досліджень базових обчислень в рамках однієї транзакції.
Ці два розвитки надихнули багато активності та захвату навколо завітів, але вони також укристалізували наше мислення про фундаментальні обмеження . Зокрема, здавалося, що без нових опкодів завіти можуть бути неможливими, оскільки дані транзакцій подавалися лише через 64-байтові підписи та 32-байтові відкриті ключі, тоді як опкоди, що підтримують BitVM, могли працювати лише з 4-байтовими об'єктами. Це розрив був названий "Малий " та "Великий ", і знаходження мосту між ними стало синонімом (принаймні у моїй думці) знайти конструкцію завіту.
Функціональне шифрування та PIPEs
Також було зауважено, що за допомогою трохи місячної математики, можливо здійснювати ковенанти повністю всередині підписів, не залишаючи великого, ніколи не залишаючи Великого . Ця ідея була сформульована Джеремі Рубіном у його доповіді FE'd Up Covenants, де описано, як реалізувати ковенанти за допомогою гіпотетичної криптопримітивної функціональної шифрування. Місяці пізніше Міша Коморов запропонував конкретну схему, яка, здається, зробила цю гіпотетичну ідею реальністю.
Це захоплюючий розвиток, хоча він стикається з двома основними обмеженнями: одне полягає в тому, що воно включає довірений налаштування, що означає, що особа, яка створює договір, здатна обійти його правила. (Це підходить для чогось такого, як сховища, в яких власник монет може довіряти тому, що не підірветься його власна безпека; але це не підходить для чогось такого, як платіжні пули, де монети в договорі не належать творцеві договору.) Іншим обмеженням є те, що воно включає передову криптографію з неясними властивостями безпеки. Це останнє обмеження зникне з додатковим дослідженням, але довірений налаштування є неодмінним для функціонального підходу до шифрування.
Колайдер
Цей огляд доводить нас до поточної ситуації: ми хотіли б знайти спосіб реалізації договорів за допомогою існуючої форми Біткойн , і ми вважаємо, що шлях до цього полягає в знаходженні якогось мосту між "Великим " підписами транзакцій та "Малим " довільними обчисленнями. Здається, що жоден опкод не може прямо сформувати цей міст (див. Додаток A до нашої статті для класифікації всіх опкодів за розмірами їх вводу та виводу). Міст, якщо б він існував, був би якоюсь конструкцією, яка б взяла один великий об'єкт і продемонструвала, що він точно дорівнює конкатенації кількох малих об'єктів. Здається, на основі нашої класифікації опкодів, це неможливо.
Але в криптографії ми часто ослаблюємо такі поняття, як "точно рівні", замість цього використовуючи поняття, такі як "обчислювально нерозрізнимі" або "статистично нерозрізнимі", тим самим уникнувши неможливих результатів. Можливо, використовуючи вбудовані криптографічні конструкції Big - хеші та еліптичні криві підписи - і дзеркалюючи їх за допомогою конструкцій BitVM в Small, ми зможемо знайти спосіб показати, що великий об'єкт є "обчислювально нерозрізним" від серії малих об'єктів? За допомогою Collider ми саме це й зробили.
Що це означає? Ну, пригадайте винагорода зіткнення хеш-функції, про яку ми згадували раніше. Премісцюється цієї винагорода полягає в тому, що будь-хто, хто може "зіткнутися" з хеш-функцією, надавши два входи, які мають однаковий вихід хеш-функції, може довести в Біґ, що вони це зробили, і таким чином вимагати винагорода. Оскільки простір входу хеш-функції набагато більший (всі байтряди розміром до 520 байт) від простору виходу (байтряди розміром точно в 32 байти), математично кажучи, має бути багато таких зіткнень. І все ж, за винятком SHA1, ніхто не знайшов швидший спосіб знайти ці зіткнення, ніж просто безперервно викликати хеш-функцію і перевіряти, чи співпадає результат з результатом попереднєї спроби.
Це означає, що у середньому для функції хешування 160-біт, такої як SHA1 або RIPEMD160, користувачеві потрібно виконати принаймні 2^80 роботи, або мільйон мільйонів мільйонів мільйонів ітерацій, щоб знайти зіткнення. (У випадку SHA1 існує скорочення, якщо користувач може використовувати вхідні дані певної форми; проте наша конструкція забороняє це, тому для наших цілей ми можемо ігнорувати цей напад.) Це передбачає, що у користувача є практично нескінченна кількість пам'яті для роботи; з більш реалістичними припущеннями нам потрібно додати ще один множник близько ста.
Якщо уявити, що SHA1 та RIPEMD160 можна обчислити так само ефективно, як Біткойн ASIC-пристрої обчислюють SHA256, то вартість такого обчислення буде приблизно такою ж, як вартість 200 блоків, або близько 625 BTC (46 мільйонів доларів). Це багато грошей, але багато людей мають доступ до такої суми, тому це можливо.
Знайти трипльне зіткнення, або три входи, які дорівнюють одному й тому ж, займе близько 2^110 роботи, навіть за дуже щедрими припущеннями про доступ до пам'яті. Щоб отримати цю цифру, нам потрібно додати ще один множник 16 мільйонів до наших витрат - це збільшить нашу загальну суму до понад 700 трильйонів доларів. Це також багато грошей, на які ніхто не має доступу сьогодні.
Суть нашої конструкції полягає в наступному: для того, щоб довести, що послідовність малих об'єктів еквівалентна одному великому об'єкту, спочатку ми знаходимо хеш-колізію між нашим цільовим об'єктом (який, як ми припускаємо, може бути перерандомізований якимось чином, інакше ми б займалися «пошуком другого образу» замість пошуку колізій, що було б набагато складніше) та «об'єктом-тестером еквівалентності». Ці об'єкти-тестери еквівалентності будуються таким чином, що їх можна легко маніпулювати як великими, так і малими.
Наша конструкція потім перевіряє, у Біткойні, що наш великий об'єкт зіштовхується з нашим тестером еквівалентності (використовуючи точно ті ж методи, що і в хеш-колізії винагороди) та що наша послідовність малих об'єктів зіштовхується з тестером еквівалентності (використовуючи складні конструкції, частково позичені з проекту BitVM, та детально описані у статті). Якщо ці перевірки пройшли успішно, то або наші малі й великі об'єкти були однакові, або користувач знайшов потрійну колізію: два різні об'єкти, які обидва зіштовхуються з тестером. За нашим аргументом вище, це неможливо.
Висновок
Поєднання малого і великого—це найважча частина нашої побудови завітів. Щоб перейти від цього щастя до справжнього завіту, потрібно зробити ще кілька кроків, які є порівняно легкими. Зокрема, ковенант спочатку просить користувача підписати транзакцію за допомогою спеціального «ключа генератора», який ми можемо перевірити за допомогою коду операції OP_CHECKSIG. Використовуючи міст, ми розбиваємо цю сигнатуру на 4-байтові фрагменти. Потім ми перевіряємо, що його nonce також дорівнював ключу генератора, що легко зробити після того, як підпис був розбитий. Нарешті, ми використовуємо методи трюку Шнорра для вилучення даних про транзакції з підпису, які потім можуть бути обмежені будь-яким способом, який забажає ковенант.
Є ще кілька інших речей, які ми можемо зробити: Додаток C описує конструкцію кільцевого підпису, яка дозволить підписати монети одним з набору відкритих ключів, не розкриваючи, який саме був використаний. У цьому випадку ми використовуємо міст для розбиття відкритого ключа, а не підпису. Це дає нам значне покращення ефективності порівняно з конструкцією пакту за технічними причинами, пов'язаними з Taproot та детально описаними в документі.
Заявка, на яку я хочу звернути увагу, коротко обговорена в розділі 7.2 статті, це те, що ми можемо використовувати нашу конструкцію угоди, щоб витягти хеш транзакції з підпису Шнорра, а потім просто повторно підписати хеш з використанням підпису Лампорта.
Чому б ми це робили? Як аргументується в вищезазначеному посиланні, підписування Лампорта таким чином робить його квантово-стійким підписом для даних транзакції; якщо ця конструкція була єдиною можливістю підпису для деяких монет, вони були б захищені від крадіжки квантовим комп'ютером.
Звичайно, оскільки на наше будівництво потрібні десятки мільйонів доларів, ніхто не зробить цю конструкцію єдиним способом підписання своїх монет. Але ніщо не заважає комусь додати цю конструкцію до своїх монет, на додачу до існуючих неквантово-безпечних методів витрачання.
Тоді, якщо ми прокинулися завтра і виявили, що існують дешеві квантові комп'ютери, які можуть ламати підписи Біткойн, ми могли б запропонувати невідкладний м'який форк, який вимкнув би всі еліптичні криві підписи, включаючи як ключ-витрати Taproot, так і опкод OP_CHECKSIG. Це фактично заморозило б монети всіх; але якщо альтернативою було б те, що монети всіх можна було вільно вкрасти, можливо, це не зробило б жодної різниці. Якщо цей м'який форк, який вимикає підписи, дозволяв би опкод OP_CHECKSIG при виклику з ключем генератора (такі підписи взагалі не забезпечують безпеку і корисні лише як будівельний блок для складних конструкцій, таких як наші), то користувачі нашої конструкції підпису Лампорта могли б продовжувати вільно витрачати свої монети, не боячись конфіскації чи крадіжки.
Звичайно, їм доведеться витратити десятки мільйонів доларів на це, але це набагато краще, ніж "неможливо"! І ми очікуємо та сподіваємося, що ці витрати PEOPLE значно зменшаться, так як люди будують наші дослідження.
Це гостьовий пост Ендрю Поелстри. Висловлювані думки повністю є їх власними і не обов'язково відображають погляди BTC Inc або Біткойн Magazine.